iT邦幫忙

2019 iT 邦幫忙鐵人賽

DAY 4
0
自我挑戰組

開源組織生態觀察筆記系列 第 4

[Day4] Bug 追蹤系統 via Bugzilla --- 介紹篇

  • 分享至 

  • xImage
  •  

這次的系列要嘗試瞭解 bug 追蹤的奧妙,進而探索 bug 的生命週期
希望能從探索的過程中領略開源組織協作的生態

為何挑選 Bugzilla 來做介紹?

接續昨天針對 GNOME-Logs GSoC 的解析,我們要來嘗試瞭解在 GitHub ISSUE 以外的 bug 追蹤系統:Bugzilla,想介紹的原因是在昨天分析的過程中有注意到 Bugzilla 有出現在 issue(github/gitlab),而且不少開放原始碼的組織就是透過 bugzilla 來管理 bug 的「報告、追蹤、討論」,如果能夠學會 bugzilla 應該是挺划算的投資,因此勾起筆者想寫篇針對 bugzilla 的介紹,並期望達到以下目的

  • 瞭解 bugzilla 的使用方式,並嘗試實際跑過一次流程
  • bugzilla 對 bug 控管的設計思維
  • bug 在 bugzilla 的生命週期

關於 Bugzilla

Bugzilla 是由 Mozilla 於 1998 以 Mozilla Public License[註1] 釋出的一款 Bug 追蹤系統,其程式碼是由 Perl 撰寫並且目前維護在 GitHub 上,根據官網統計公開 bugzilla 的公司、組織、專案約 137,如果包含非公開的可能有十倍以上,而在 137 家中有相當多知名的組織,如 GCC、GNOME、KDE、Red Hat、Eclipse、Gentoo、Linux Kernel...等等,詳細列表可以在 Link 瞭解

以上是相關超連結,如果你點進 GitHub 進去應該會發現沒有 Issue 的區域,這是因為 bugzilla 本身的 bug 是透過 bugzilla 來管理~挺有趣的!

如何使用 Bugzilla?

今天的示範會遵從官方文件的指引來走。而嘗試的 bugzilla 就用官方自身維護的 bugzilla 來嘗試,雖然 GitHub 有提供一個類似沙盒的連結,不過目前是無法使用的狀態。
因此今天的觀察筆記會站在 Mozilla 的 bugzilla 的立場來紀錄,內文的 bugzilla 就是指 bugzilla hosted by Mozilla

這幾天會來深入官方指引一探究竟

  • 第二章 User Guide
    • 2.1. Creating an Account
    • 2.2. Filing a Bug
    • 2.3. Understanding a Bug
    • 2.4. Editing a Bug
    • 2.5. Finding Bugs
    • 2.6. Reports and Charts
    • 2.7. Pro Tips
    • 2.8. User Preferences
    • 2.9. Installed Extensions
一開始會需要先註冊一個帳號,在其帳號註冊頁面可以看到一些注意事項
  • 請閱讀 如何撰寫 Bug Report
  • 在 bugzilla 上你的留言、E-mail 都是公開的,請知悉這些規定。(也因為如此有些人會使用備用 E-mail)[註2]
  • 在 bugzilla 的產生的內容需遵守 Moziila 的開源政策來授權
  • 請遵守相關的禮儀社群參與指導原則

這邊值得注意的是第三點
如果對社群參與不熟悉的朋友可以嘗試去了解第三點的授權政策,,對於參與開源專案來說,通常貢獻的內容都必須遵照社群定義好的授權條款,另一個常見的名詞 Code of Conduct 也就是行為準則,在 GitHub 上進行 PR ,你的程式碼也是 under the licence in the project。

在註冊的過程中在欄位裡面有個 REALNAME,文件裡面也提到建議填寫真實名稱,目前不曉得為何要這樣做,筆者會再找朋友瞭解看看這項建議的用意。

Once you confirm your registration, Bugzilla will ask you your real name (optional, but recommended) and ask you to choose a password. Depending on how your Bugzilla is configured, there may be minimum complexity requirements for the password

建立完成後初始頁面如下

Imgur

2.1 Filing a bug

這章節開宗明義就說

Years of bug writing experience has been distilled for your reading pleasure into the Bug Writing Guidelines.
看來得好好深入 Bug Writing Guidelines 來提煉前人的經驗了!

先讓我們在這邊告個段落,因為 Landfill 官方提供的沙盒掛了,希望能找到代替的方式,不然不能實作看看有點可惜,因此今天第二章的介紹就先到這邊,明天會從頭把第二章的內容接起來介紹。

如果有朋友知道哪邊可以練習 Bugzilla 的使用,再請留言提供給我,謝謝 :>

結語 & 預告

今天在看文件,發現 Bugzilla 本身並沒有中文化,因此明天在進行第二章介紹前會先回報 Bugzilla 文件中文化的可能性,再接續今天 bugzilla 的指引,一步一步去瞭解 Bugzilla 的使用方式。而另外這個主題也會有衍伸的題目「如何回報一個好的 bug」,這應該會是相當重要的議題,筆者會在思考何時端出這個章節進行介紹。

備註與參考

[註1] 該協定融合了BSD授權條款和GNU通用公眾授權條款的特性,追求平衡專有軟體和開源軟體開發者之間的顧慮。
[註2] 底下是註冊帳號,收到的信件再次提醒的內容
PRIVACY NOTICE: Bugzilla is an open bug tracking system. Activity on most
bugs, including email addresses, will be visible to the public. We recommend
using a secondary account or free web email service (such as Gmail, Yahoo,
Hotmail, or similar) to avoid receiving spam at your primary email address.

[Reference]
Icon provided in https://www.bugzilla.org/img/buggie.png


上一篇
[Day3] GNOME GSoC Project 的觀察筆記 --- 解析篇
下一篇
[Day5] Bug 追蹤系統 via Bugzilla --- 初探篇
系列文
開源組織生態觀察筆記30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言